1. Field of the Invention
This invention relates generally to database recovery procedures and specifically to a dual database system that employs concurrent copy and update operations to recover from failure of either database without interrupting availability of the other database.
2. Discussion of the Related Art
An integral part of any database system is a recovery scheme for the detection of failures and the restoration of the database to a consistent state. A xe2x80x9ctransactionxe2x80x9d is a logical unit of work referencing a sequence of queries (reads) and updates (writes, including deletes, inserts, and changes) that transforms a consistent state of a recoverable resource into another consistent state without necessarily preserving consistency at all intermediate points. For the purposes of this discussion, a database is considered as a typical instance of such a recoverable source.
Transactions are executed on computer-implemented database processing systems that may be considered to operate in several modes, including a xe2x80x9cprocessingxe2x80x9d mode and, in the event of failure, one or more xe2x80x9crecoveryxe2x80x9d modes. The existing art is replete with examples of fault-tolerant, transaction-oriented database processing systems, including checkpoint and incremental recovery log systems, shadow-paging systems and redundant database systems.
The redundant database systems known in the art are exemplified by the system disclosed in U.S. Pat. No. 5,170,480 issued to Mohan et al. who disclose a synchronous distributed database system that provides for storing a consistent copy of a database in two locations. Mohan et al. teach the use of a tracking system that operates in conjunction with an xe2x80x9cactivexe2x80x9d database system to maintain a xe2x80x9ctrackingxe2x80x9d database in a second redundant database system, where the tracking database is a replica of the active database maintained in the active database system. The transaction log redo records are organized into queues representing separate units of transfer (pages) before transmission from the active database system to the redundant database system, thereby more efficiently maintaining tracking database consistency. Their dual database system permits updating of the active database even when the tracking database is not available and eliminates the usual requirement for independent serialization of redundant database system operations.
When failure occurs in the active database system of a dual database system such as that described by Mohan et al., a redundant database is available as a checkpoint for recovery of the active database in conjunction with the usual transaction log forward recovery procedures known in the art. Unfortunately, neither database is available for active use during such a recovery. Moreover, if one of the two database systems is down for a significant period of time, the size of the forward recovery transaction log necessary for recovering the failed database can grow to unacceptably large size. This is because the forward recovery log must maintain a record of all transactions occurring during the failure period, which are then applied to the recovered consistent database to bring it up to a concurrent consistent state. Alternatively, a failed database can be recovered merely by making a new copy of the redundant database following repair of the active database system failure. However, when the redundant database is remotely located from a very large active database, the mechanics of copying the entire database to the remote location may present unacceptable difficulties. For instance, to ensure consistency, the active database must normally be locked until completion of the database copying process. Thus, all incoming transactions must be accumulated until the active database is unlocked and this accumulation may reach unacceptably large size.
Practitioners have proposed solutions to these problems with only limited success. For instance, in European patent EP-51690-A, Baker et al. disclose an invention that permits a backup to be taken of a nonredundant database while that database remains open for transaction processing by frequently recording a complete set of tie-up records in the transaction log. The tie-up records provide sufficient data to recover a checkpoint database copy, and the high checkpoint frequency permits recovery from a relatively small log upon failure. Thus, Baker et al. do not avoid the usual database system suspension during forward recovery upon failure. Although Baker et al. show how to avoid suspending database operation during checkpoint backup copying, the dual database system also solves this problem by continuously maintaining the redundant database.
Accordingly, there is a clearly-felt need in the art for a dual database system that maintains two databases with identical entries for fault tolerance, where the xe2x80x9cactivexe2x80x9d database is always available during and after system failures. Such a system must permit failure repair without interrupting system operation and must also provide means for recreating the failed backup database following repair without interrupting system operation. That is, the xe2x80x9cactivexe2x80x9d database must remain available for normal system queries and updates while the xe2x80x9credundantxe2x80x9d database is being recreated following repair of a system failure. The recreated xe2x80x9credundantxe2x80x9d database must reflect all intervening updates made to the active database during recovery, thereby arriving at a concurrent consistent state following such recovery.
The usual practice known in the art for forward recovery from an earlier consistent (checkpoint) database copy using a log of subsequent transactions cannot solve these problems. First, if the failed database is down too long, the forward recovery log becomes too large to permit recovery of a current consistent database from the earlier checkpoint copy. Secondly, incoming transactions cannot be processed during forward recovery and must be accumulated, making the necessary forward recovery log even larger. Finally, if the forward recovery log is frozen, then the entire database system must be halted during forward recovery, which interrupts continuous availability.
These unresolved problems and deficiencies are clearly felt in the art and are solved by this invention in the manner described below.
This invention provides a continuously-available fault-tolerant database by combining the copy operations necessary to reconstruct a failed database with the database transaction operations incoming during recovery. Thus, the xe2x80x9cactivexe2x80x9d (surviving) database system copies one record at a time while interleaving updates into the operation stream at the xe2x80x9credundantxe2x80x9d (recovering) database system. These concurrent redundant database system operations are queued and interleaved with the normal active database transaction processing operations according to a queue thresholding test. When the copying completes, the redundant database is fully recovered into a concurrently consistent state and the continuing (echoed) incoming update operations in the redundant database system serve to maintain the concurrent consistency of the redundant database until another failure occurs. This invention requires interchangeability of the operating status (active or redundant) of each of two database systems and identifiability of each database record by some unique Record Identification Key (RIK).
It is an object of this invention to provide a dual database transaction processing system that is continuously available during recovery from the failure of either of two database processing systems. It is an advantage of the system of this invention that transaction processing activities can be continued uninterrupted during the failure of either database system and also during recovery of the failed database.
It is another objective of the system of this invention to minimize requisite transaction log size and complexity. It is a feature of the dual database system of this invention that transaction log entries are required only during the failure of either database and are then required only to back up the remaining active database during failure and recovery of the second database. Otherwise, no transaction log is necessary.
The foregoing, together with other objects, features and advantages of this invention, will become more apparent when referring to the following specification, claims and accompanying drawing.